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Detailed Office Action 

1 . The Office action of December 8, 2008 is withdrawn and the following action is 
taken. 

2. Claims 1, 3-6, 8-16 are presented for examination. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 15-16 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Loucks et al, (hereinafter Loucks) U.S. Patent No. 5,634,122 in view of Johnson et 
al, (hereinafter Johnson) U.S. Patent No. 5,175,851. 

5. As to claim 15, Loucks disclose the invention substantially as claimed, Loucks 
disclose including a program embedded on a computer-readable storage medium, 
wherein the program is executed on a server device for controlling tokens for rights to 
file reading and writing by a first client connected via a storage device and network 
[see Loucks, col. 6, lines 8-58] (tokens represent an authorization to perform a 
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read/write token permits to client from server) wherein said first client requests a 
token for rights to file reading or writing [col.9, lines 55-67](write token requested by 
a client), and wherein said program cause the server device to : send a request for a 
return of said token for rights to file, to a second client that holds rights to read or 
write on a file [see Loucks, col. 7, lines 57-61] (mtkr maintains a list of the acquired 
tokens, and when mtkr receives a "token revoke " request from mtkm, it returns the 
required token mtkm as requested). Wherein said request includes information 
identifying said first client that requested said token for said file, and information 
indicating a level of said token requested by said request client, said level being either 
read or write [see col.9, lines 55-67] {Token is a write token requested by a client). 

6. However, Loucks does not explicitly disclose sending a token revoke request for 
return of a token for writing rights file. 

7. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses sending a token revoke request for return of a token for writing 
right file [see Johnson col. 11, lines 35-48, and col. 13, lines 28-45] {server send 
revoke token request for return write token to client). 

8. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have sending a token revoke request 
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for return of a token for writing right file, for the purpose of allows more efficient use 
of the data under most circumstances [see Johnson col. 8, line 65 to col.9, line 8]. 

9. As to claim 16, Loucks disclose the invention substantially as claimed, Loucks 
disclose including a program executed on a client device for controlling rights to 
reading and writing of files stored on a storage device connected by a network, by 
utilizing tokens managed by a server [see Loucks, col.6, lines 8-58] (tokens represent 
an authorization to perform a read/write token permits to client from server), 
wherein: said program functions as a means for sending files for said token held in 
said storage section to a client device requesting said token for said file, when a 
request to revoke a token for rights file is sent from said server [see Loucks, col. 7, 
lines 57-61] (mtkr maintains a list of the acquired tokens, and when mtkr receives a 
"token revoke " request from mtkm, it returns the required token mtkm as requested). 
However, Loucks does not explicitly disclose sending a token revoke request for 
return of a token for writing rights file. 

10. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses sending a token revoke request for return of a token for writing 
right file [see Johnson col. 11, lines 35-48, and col. 13, lines 28-45] {server send 
revoke token request for return write token to client). 

1 1 . Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
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variable length with the teachings of Loucks to have sending a token revoke request 
for return of a token for writing right file, for the purpose of allows more efficient use 
of the data under most circumstances [see Johnson col. 8, line 65 to col. 9, line 8]. 

12. Claims 6, and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Loucks et al, (hereinafter Loucks) U.S. Patent No. 5,634,122 in view of Johnson et 
al, (hereinafter Johnson) U.S. Patent No. 5,175,851, and further in view of John 
H. Foulston (hereinafter Foulston) U.S. Patent No. 5,884,30. 

13. As to claim 6, Loucks discloses the invention as claimed, Loucks discloses a file send 
and receive method utilized in a distributed file system, wherein said distributed file 
system includes a storage device for holding files [see fig.5 of Loucks, and col. 7, 
lines 30-37] (files are stored on non-volatile hard disk 516 and volumes or filesets 
514), multiple clients for carrying out file operations on said storage device [see 
Loucks, col.5, lines 60-65, and col.7, lines 38-51] (client A and client B access to 
carry out file volume by using exporter 512 MDFS), a server using tokens to control 
rights to file reading and writing operations by the client [see Loucks, col.6, lines 8- 
58] (tokens represent an authorization to perform a read/write token permits to client 
from server), and a network connecting said clients [see fig.5 of Loucks, col. 7, lines 
40-44] (client A and client B communicate with 512 via network 506), and said 
storage device [see fig.5 of Loucks, and col. 7, lines 30-37] (files are stored on non- 
volatile hard disk 516 and volumes or filesets 514 connect to network 506) said server 
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[see fig. 5 ofLoucks, network 506 connect with server 500] said method comprising: 
making a request to said server for a token for rights to perform said file operations 
wherein a first client makes the request to said server [see Loucks, col. 6, lines 12-18] 
(mtkr 418 requester request tokens); sending, by said server, said token request to a 
second client that holds write operation rights to said file, so as to request a return of 
the token for said write operation rights [see Loucks, col. 6, lines 19-27] (mtkm sends 
revoke token requests to client (i.e., mtkr 418 of an MDFS client who acquired list of 
tokens)), wherein said token revoke request includes information identifying the first 
client that requested the token for said file [see Loucks, col. 7, lines 57-61] (mtkr 
maintains a list of the acquired tokens, and when mtkr receives a "token revoke " 
request from mtkm, it returns the required token mtkm as requested), and information 
indicating a level of the token requested by said first client, said level being either 
read or write [see col. 9, lines 55-67] {Token is a write token requested by a client); 

14. However, Loucks does not explicitly disclose sending a token revoke request 
containing information on a client requesting said file, and information showing the 
contents of a token said client is requesting the return of the token for write operation 
rights. 

15. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses sending a token revoke request containing information on a client 
requesting said file, and information showing the contents of a token said client is 
requesting the return of the token for write operation rights [see Johnson col. 11, lines 
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35-48, and col. 13, lines 28-45] (server send revoke token request for return write 
token to client). 

16. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have a containing information on a 
client requesting said file, and information showing the contents of a token said client 
is requesting, for the purpose of allows more efficient use of the data under most 
circumstances [see Johnson col. 8, line 65 to col. 9, line 8]. However, Loucks does 
not explicitly disclose sending, by said second client that received said token revoke 
request the file for said token held in said memory section, to the first client that 
requested the token for said file. 

17. In the same field of endeavor, Foulston discloses (e.g., Updating distributed data files 
using active token distributed at different times to different sites). Foulston discloses 
sending, by said second client that received said token revoke request the file for said 
token held in said memory section, to the first client that requested the token for said 
file [Foulston, col.4, lines 9-14, and col.45] (granting permission for file transfer the 
token and latest version are returned from node G (second client) to node A (first 
client)). 

18. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Foulston' s teachings of 
Updating distributed data files using active token distributed at different times to 
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different sites with the teachings of Loucks, for the purpose permits update access to 
the data file only at the node currently holding the respective data token [see col.2, 
lines 5-7]. 

19. As to claim 8, Loucks the file filed send and receive method according to claim 6, 
wherein the file relating to said token sent from said first client that received the 
token revoke request to said server for said second client that requested said file token 
[see Loucks, col. 7, lines 57-61] (when mtkr receives a "token revoke" request from 
mtkm (i.e., server), it returns list of tokens acquired to server as requested). 
However, Loucks does not explicitly disclose the latest information on said storage 
device does not show. 

20. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses the latest information on said storage device does not show [see 
Johnson, col.5, lines 5-8] (the file may not be accessing the latest updated data that 
has just been written). 

21 . Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have the latest information on said 
storage device does not show, for the purpose of allows more efficient use of the data 
under most circumstances [see Johnson col. 8, line 65 to col.9, line 8]. 
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22. Claims 1, 3, and 11-12 are rejected under 35 U.S.C. 103(a) as being unpatentable 
overLoucks etal, (hereinafter Loucks) U.S. Patent No. 5,634,122 in view of 
Johnson etal, (hereinafter Johnson) U.S. Patent No. 5,175,85, and further in view 
of John H. Foulston (hereinafter Foulston) U.S. Patent No. 5,884,30 and further in 
view of Saidenberg et al, (hereinafter Saidenber) Publication No. US 
2003/0110117 Al. 

23. As to claim 1, Loucks disclose the invention substantially as claimed, Loucks disclose 
including a distributed fde system comprising: a storage device for holding files [see 
fig. 5 of Loucks, and col. 7, lines 30-37] {files are stored on non-volatile hard disk 
516 and volumes or filesets 514), multiple clients for carrying out file operations on 
said storage device [see Loucks, col.5, lines 60-65, and col. 7, lines 38-51] {client A 
and client B access to carry out file volume by using exporter 512 MDFS), a server 
using tokens to control rights to file reading and writing operations by the clients [see 
Loucks, col. 6, lines 8-58] (tokens represent an authorization to perform a read/write 
token permits to client from server), and a network connecting said clients [see fig.5 
of Loucks, col. 7, lines 40-44] (client A and client B communicate with 512 via 
network 506), and said storage device [see fig.5 of Loucks, and col. 7, lines 30-37] 
(files are stored on non-volatile hard disk 516 and volumes or filesets 514 connect to 
network 506) said server [see fig.5 of Loucks, network 506 connect with server 500], 
wherein said server contains a token revoke request means (i.e., mtkm 420 located in 
server 400) for sending a token revoke request for demanding a return of a token 



Application/Control Number: 10/736,630 Page 10 

Art Unit: 2444 

granting rights to write on said file, to a first client that holding said token [see 
Loucks, col. 6, lines 19-27] (mtkm sends revoke token requests to client (i.e., mtkr 418 
of an MDFS client who acquired list of tokens) when a specific(i.e., write or read) 
token is requested by another client), 

wherein said token revoke request means sends said token revoke request [see 
Loucks, col. 6, lines 19-27] (mtkm sends revoke token requests to client (i.e., mtkr 418 
of an MDFS client who acquired list of tokens)), which including information 
identifying a second client that requested said file, and information indicating a level 
of said token requested by said second client, said level being either read or write [see 
col. 9, lines 55-67] (Token is a write token requested by a client); and 
wherein said first client comprises a memory section for holding file data [see 
Loucks, col. 7, lines 52-60] (mtkr (i.e., memory session) located in client 402, 408, 
and maintains a list of acquire token of client) and a data output means for sending 
said file held in said memory section and relating to said token, to said server for said 
second client that requested said token when said token revoke request is received 
[see Loucks, col. 7, lines 57-61] (mtkr maintains a list of the acquired tokens, and 
when mtkr receives a "token revoke " request from mtkm, it returns the required token 
mtkm as requested). 

24. However, Louck and Johnson do not explicitly disclose a file is loaded from storage 
device to client. 

25. In the same field of endeavor, Saidenberg discloses (e.g., system and method for 
providing integrated applications availability in a networked computer system). 
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Saidenberg discloses a file is loaded from storage device to client [see Saidenberg, 
page. 3, paragraph 0045] {the computer program may be loaded from data storage 
devices into computer RAM). 

26. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Saidenberg's teachings of 
a system and method for providing integrated applications availability in a networked 
computer system with the teachings of Loucks to have a file is loaded to client from 
storage device, for the purpose of providing secure, convenient and integrate access to 
a variety of applications, tools and content in network [see Saidenberg, page. 1, and 
paragraph 00 11 ]. 

27. However, Loucks does not explicitly disclose sending a token revoke request 
containing information on a client requesting said file, and information showing the 
contents of a token said client is requesting. 

28. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses sending a token revoke request containing information on a client 
requesting said file, and information showing the contents of a token said client is 
requesting [see Johnson col. 11, lines 35-48, and col. 13, lines 28-45] {server send 
revoke token request for read token or write token to read/write granted token). 

29. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
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variable length with the teachings of Loucks to have a containing information on a 
client requesting said file, and information showing the contents of a token said client 
is requesting, for the purpose of allows more efficient use of the data under most 
circumstances [see Johnson col. 8, line 65 to col.9, line 8]. 

30. As to claim 3, Loucks discloses the distributed file system according to claim 1, 
wherein the file relating to said token sent from a said first client to the server for said 
second client that requested said token, contains information not already appearing in 
the latest information in said storage device [see Loucks, col. 7, lines 57-61] (when 
mtkr receives a "token revoke" request from mtkm (i.e., server), it returns list of 
tokens acquired to server as requested). However, Loucks does not explicitly 
disclose the latest information on said storage device does not show. 

31. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses the latest information on said storage device does not show [see 
Johnson, col. 5, lines 5-8] {the file may not be accessing the latest updated data that 
has just been written). 

32. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have the latest information on said 
storage device does not show, for the purpose of allows more efficient use of the data 
under most circumstances [see Johnson col. 8, line 65 to col.9, line 8]. 
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33. As to claim 11, Loucks disclose the invention substantially as claimed, Loucks 

disclose including a client device utilized in a distributed file system, wherein said 
distributed file system includes a storage device for holding files [see fig. 5 of Loucks, 
and col. 7, lines 30-37] {files are stored on non-volatile hard disk 516 and volumes or 

filesets 514), multiple clients for carrying out file operations on said storage device 
[see Loucks, col.5, lines 60-65, and col.7, lines 38-51] (client A and client B access to 
carry out file volume by using exporter 512 MDFS), a server using tokens to control 
rights to file reading and writing operations by the client [see Loucks, col.6, lines 8- 
58] (tokens represent an authorization to perform a read/write token permits to client 

from server), and a network connecting said clients de vices [see fig. 5 of Loucks, col. 
7, lines 40-44] (client A and client B communicate with 512 via network 506), and 
said storage device [see fig.5 of Loucks, and col. 7, lines 30-37] (files are stored on 
non-volatile hard disk 516 and volumes or filesets 514 connect to network 506) said 
server [see fig. 5 of Loucks, network 506 connect with server 500], said first client 
device comprising: a memory section for holding file data [see Loucks, col. 7, lines 
52-60] (mtkr (i.e., memory session) located in client 402, 408, and maintains a list of 
acquire token of client); and a data output means for sending a relating to a token held 
in said memory section (i.e., mtkr maintains a list of the acquired tokens) to a second 
client device requested the token for said file when a request for returning said token 
for rights is received by said first client device from said server [see Loucks, col. 7, 
lines 57-61] (mtkr maintains a list of the acquired tokens, and when mtkr receives a 
"token revoke " request from mtkm, it returns the required token mtkm as requested). 
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Wherein said request includes information identifying said second client that 
requested said token for said file, and information indicating a level of said token 
requested by said second client, said level being either read or write [see col.9, lines 
55-67] {Token is a write token requested by a client). 

34. However, Loucks and Johnson do not explicitly disclose a file is loaded from storage 
device to client. 

35. In the same field of endeavor, Saidenberg discloses (e.g., system and method for 
providing integrated applications availability in a networked computer system). 
Saidenberg discloses a file is loaded from storage device to client [see Saidenberg, 
page.3, paragraph 0045] (the computer program may be loaded from data storage 
devices into computer RAM). 

36. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Saidenberg's teachings of 
a system and method for providing integrated applications availability in a networked 
computer system with the teachings of Loucks to have a file is loaded to client from 
storage device, for the purpose of providing secure, convenient and integrate access to 
a variety of applications, tools and content in network [see Saidenberg, page. 1, and 
paragraph 0011 ]. 

37. However, Loucks does not explicitly disclose sending a token request for return of a 
token for writing right file. 

38. In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
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Johnson discloses sending a token revoke request for return of a token for writing 
right file [see Johnson col. 11, lines 35-48, and col. 13, lines 28-45] (server send 
revoke token request for return write token to client). 

39. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have sending a token revoke request 
for return of a token for writing right file, for the purpose of allows more efficient use 
of the data under most circumstances [see Johnson col. 8, line 65 to col. 9, line 8]. 

40. As to claim 12, Loucks discloses the invention as claimed, Loucks discloses a client 
device according to claim 1 1 , wherein the file relating to said token sent to said server 
for the second client that requested said token [see Loucks, col. 7, lines 57-61] (when 
mtkr receives a "token revoke" request from mtkm (i.e., server), it returns list of 
tokens acquired to server as requested). However, Loucks does not explicitly 
disclose the latest information on said storage device does not show. 

41 . In the same field of endeavor, Johnson discloses (e.g., system and method for 
controlling client machine access to a portion of a file with a variable length). 
Johnson discloses the latest information on said storage device does not show [see 
Johnson, col. 5, lines 5-8] (the file may not be accessing the latest updated data that 
has just been written). 

42. Accordingly, it would have been obvious to one of ordinary skill in the networking 
art at the time the invention was made to have incorporated Johnson's teachings of 
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system and method for controlling client machine access to a portion of a file with a 
variable length with the teachings of Loucks to have the latest information on said 
storage device does not show, for the purpose of allows more efficient use of the data 
under most circumstances [see Johnson col. 8, line 65 to col.9, line 8]. 
Allowable Subject Matter 

43. Claims 5,10, and 14 would be allowable if rewritten to overcome the claim 
objection(s) above, set forth in this Office action and to include all of the limitations 
of the base claim and any intervening claims. 

44. The following is a statement of reasons for the indication of allowable subject matter: 
In interpreting the claims, in light of the specification, Examiner finds claims 5,10, 
and 14 to be patentably distinct from the prior art records. The art of records fails to 
teach or suggest individually or in combination that "token is linked to file range, 
data output means sends data in a range among files linked by token to server of 
client request token, and performs synchronous processing on storage device by 
writing data in arrange among files not linked by token, the data output means 
decides whether to send token of held file to server of the client requesting the token, 
or write file in storage device and perform synchronous processing on said storage 
device, based on the input/output capacity of network and said storage device", as 
claimed in claims 5, 10, and 14. 

Conclusion 
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45. Any inquiry concerning this communication or earlier communications from the 

examiner should be directed to Tammy T. Nguyen whose telephone number is 

571-272- 3929. The examiner can normally be reached on Monday - Friday 8:30 -5:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

supervisor, William Vaughn can be reached on 571-272-3922. The fax phone number for the 

organization where this application or proceeding is assigned is 571-273-8300. Information 

regarding the status of an application may be obtained from the Patent Application Information 
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